Day1 質問・雑談コーナー (2021)
Scrapbox上でYoutube live見れるの便利だ
LIveが終わると、そのままarchiveへのリンクになるのか。なるほど
20:10-20:30の質疑応答コーナーでこちらのページに質問を書き込んでいただけるとrakusai.icon yuiseki.icon akix.iconがお答えします！
登壇中、登壇者のスライドに直接コメントしてもOKですnyanco.icon
アクセスすると{"name":"NotMemberError","message":"You are not a member."}が返ってきます
ご指摘ありがとうございます！akix.icon
今、画像2件を置き換えてみたのですが、見えてますでしょうか？akix.icon2021/3/9 19:09
見えました！/icons/感謝.iconです！takker.icon
ありがとうございます！🎉akix.icon
ホントだ！
雑談ばっかり見てた... 増井俊之.icon
質問コーナー、だと質問じゃないことは書きづらい感じがあるので、何でも書けるようなページがあるといいですよねyosider.icon
たしかに。質問・雑談コーナーとかの方がよかったのかもshokai.icon
Scrapbox儲かってますか？yosider.icon
儲かっていてほしい
無料でフルアクセスできると逆に不安になってしまう現象があるmtane0412.icon
外国の人がScrapboxめちゃくちゃ気に入ってくれたけど収益面はやっぱり気になってて、情報ここにストックするのにちょっと不安がってた
それはすみません。もうちょっと安定感があるように見せていきたいですねrakusai.icon
実際は、収益だけでなくアクセスも伸びていて、nota tech confでのshokaiの話も、scrapboxのスケーラビリティの確保の話になると思います
エクスポートはできます
大事yosider.icon
帳簿の見方よくわかってないけど、インフラコストの10倍ぐらい売り上げあるのですぐサービスが消える事はないと思いますshokai.icon
scrapboxにはいつもお世話になっているので、ありがたいことでございますimo.iconyosider.iconerniogi.iconfoldrr.iconmtane0412.iconyamanoku.icontakker.iconmactkg.icon
まぁ調達もしましたしね 増井俊之.icon
儲かってます！rakusai.icon
サブスクリプション売上は、この5年で10倍以上になっています
/icons/すごい.iconmtane0412.iconkarupanerura.iconyosider.iconnagayama.iconerniogi.iconyamanoku.icontakker.icon
かつ、黒字化しています
コロナ禍も追い風になっています（そんなに強調するつもりはないですが）
実は、売上に伴って採用も増えていて、絶対数は多くないですが、現メンバーの半分はこの2年以内に入ってきた人かも
モックアップ作るのはSandbox環境とかある感じですか？yamanoku.icon
モックアップはフルスクラッチで作っていただいていますyuiseki.icon
ご回答ありがとうございます！yamanoku.icon
デザイナーさんが作っている感じなんですねyamanoku.icon
UIの振る舞いに限っていえばデザイナーがやることは多いんですが、機能の提案や実際のデータを伴う検証に関しては皆がモックアップに参加してますtakeru.icon
なるほどなるほどyamanoku.icon
UIの振る舞いについては餅は餅屋ですねyamanoku.icon
GCSってことはGCPで稼働していると思うのですがDatastore(Firestore)を使わずに（自前で？）Mongo DBを運用しているのは何か理由があるのでしょうか？karupanerura.icon
「運用できるなら」という条件がつくけど Mongo のほうが Firestore より楽じゃねssig33.icon
MongoDBの運用がそもそも大変じゃないかなと思っていて、それならFirestore向けにEntityを設計したほうが楽そうな印象karupanerura.icon
hiroshi.icon MongoDB サーバー運用たしかにめんどくさいですね。 MongoDB Atlas が GCP でも local SSD 対応したら移行したい...
hiroshi.icon Firestore よく知らなくて (Firebase ならわかりますが) Datastore も古い App Engine のときの知識ですが、 Mongo みたいな複雑なクエリ (aggregation とかも)できなくて index 組み合わせとかいろいろ制限があったりとか、何より Google にロックインされちゃうのがキビシイ感じですね
個人的にはDBはなにつかってもその製品にロックインされるのであまり気にしなくなりました。複雑なクエリが打てないのはそうで、代わりにアプリケーション側でやったり、トリガで集計したりする感じになりますねkarupanerura.icon
Firestoreはたしかに、高速性に過剰に振っているのでアプリケーション側で頑張る事が多いですねyuiseki.icon
GCPに行く前からGyazoはmongoでやっていたので、特に移行する理由がなかったのかもshokai.icon
なるほど。GCPにはどこかから移管したんですねkarupanerura.icon
AWSでしたshokai.icon
ありがとうございます！mongoid便利そうでよさそうですねkarupanerura.icon
Firestoreだとcache周りがめんどくさいですtakker.icon
自分が調べた範囲ですが、単純なcache機能しか使えなさそうでした
自分が使っていた範囲だとGAEから使っていたからかレイテンシーはほとんど気にならずキャッシュなしで十分なパフォーマンスが出ていてキャッシュはあまり考えなくてよかったですねkarupanerura.icon
/icons/なるほど.icon
service workerで全てのfetchを横取りして、networkから取得するかcacheから取得するかを細かく制御するのは実装が難しそうです
Reactを使っている場合、SWRなどの概念を取り入れると破滅が防げるらしいですyuiseki.icon 議論が開発メンバー全員集まって通話してるとのことですが、ファシリテーションはどうやって、どういう感じで各自発言するタイミングとか設けてたりとかしてますか
質問の意図としてはリモートでどうやって議論が終結させるのかが気になった
事前にScrapbox上に議題を書いてもらいますyuiseki.icon
アナウンス
進捗
相談・議論
カーソルがぶつかり合ったりしませんか？yosider.icon
定例会議のアジェンダは、先に入力欄をテンプレとして作ってしまうのがコツですyuiseki.icon
アナウンス
ひとつめ
ふたつめ
進捗
Aさん
abc
Bさん
abc
Cさん
abc
…
相談・議論
相談ひとつめ
相談ふたつめ
etc...
それぞれがそれぞれ関係ある場所に書き込む感じかyosider.icon
ありがとうございます
勉強になりましたyamanoku.icon
Mongoとかのドキュメント突っ込む系DB、モデルの更新タイミングによってキーがあったり無かったりしてハンドリングが大変そうなイメージがあるんですがそうでも無いですか?niboshi.icon
スキーマの更新やマイグレーションに時間がかからないので、むしろモデル更新は楽かも？rakusai.icon
ただし、古いデータが残ったりするようなバグを生む怖さはちょっとありますね
なるほど！V1ではこのキーあったけどV2で一旦無くなってV3でちょっとフォーマット変えて復活したんだよな〜みたいになってくると、モデルの歴史を知らなきゃいけなくて大変かも?と思って質問しました。niboshi.icon
その場合は、そうですね。rakusai.icon
あと、最近だと、異なるバージョンを同時にリリースしたり、リリース後、リバートしたりすることも多いですね。rakusai.icon
↑の例だと、V1とV2が両方リリースされているような状態とか。V1からV2にゆるやかにデプロイされていくパターンとか
それはめちゃめちゃややこしそうですね...異なるバージョンで同じリソース触りはじめるとわけわからなりそうですniboshi.icon
はい。rakusai.icon
Gyazoだと昔の経験では、DBサイズが1000万行、50GBとか超えてくるとスキーマ変更はmysqlで30分はかかりました
なので、スキーマ変更を伴うようなデプロイするときは、どっちのDBでも考えることが多いですね...
それぐらいの規模になるとマイグレーション不要なのはメリット大きいですねniboshi.icon
mongoidやmongooseはschema定義してfieldが無ければdefault返ると機能とかあって、なんかそういうのでなんとかなってますねshokai.icon なるほど、クライアント側でスキーマをある程度保証する仕組みがあるんですねniboshi.icon
あとはアプリケーションコードが複雑になるschema変更はbatchでさっさと理想的なschemaに揃える
言われてみると、確かにバッチでスキーマ揃えればいいですね。急になんとかなる気がしてきました。niboshi.icon
静的型付け言語とかだとより良い感じになりますね
Gyazoに関して言うと、masterブランチのmongoidの定義が絶対正義なのでそんなにシッチャカメッチャカにはなっていないですyuiseki.icon
Gyazoでのフロントエンドスタイル実装はCSS in JS？ CSS Modules？
グラフィック的なデザインをフィックスしてから実装される感じですか？nagayama.icon
あとモックの精度ってどのくらいでしょうか？割と作り込む感じでしょうか？nagayama.icon
ちょっとした機能追加や改善修正はプロトタイプ実装ファーストですyuiseki.icon
複雑になりそうなUIだけ、ワイヤーフレームやモックアップを作って議論してから実装しますyuiseki.icon
モックの精度は、完成に近いものですyuiseki.icon
JSのアニメーションやCSSをそのままProductionに取り込めるレベル
なるほどありがとうございます！！nagayama.icon
Gyazoのserver容量が気になりますtakker.icon
この前Google Photoが容量の関係で画像のupload総量に制限をかけ始めたので、Gyazoでもいずれそういう問題が発生するのではないかと気になりました
むしろアップロード制限を緩和してもいいのではというような議論をしていたりしますyuiseki.icon
/icons/わーい.iconyosider.icon
upload制限あったんですか
この前めっちゃサイズの大きいpngファイルを数百枚に送ったらnetworkがガタガタになりました
serverに負荷かけちゃってごめんなさい
ストレージより転送とかのほうがコスト高い
そうですねrakusai.icon
scrapboxで、誰かが他人の文書を間違ってごっそり消してしまったことはありますか?Sakayori_Hideki.icon
技術者が多ければ、間違っても戻せると思うのですが
一般の会社では、操作になれていない人の操作ミスが少し怖い感じはあるのです。
https://gyazo.com/20fac1dae8f647e42fbaf4d252252b36.mp4
右上のRestore xのプロトタイプ感
当然だけどテロメアは死んじゃうか
なるほど。ありがとうございます。気軽に書けることとの、やむを得ないトレードオフではあるのかもしれませんね。Sakayori_Hideki.icon
編集が高頻度だとpage historyがちゃんとできてるのか気になるyosider.iconerniogi.icon
すべての編集をリアルタイムにはhistoryに入れてないので、書いた瞬間に消されたのは無理ですshokai.icon
間違えてページ遷移してしまい、Ctrl+Zが使えなくなったときとかに便利です
書いた瞬間の編集内容も取得できます
まあまた書けばいいんですよ。今書いたばかりなら何度も書くと洗練されてくる！！shokai.icon
PCにあまり触ったことがないような人は、編集権限を落として、クリックしないと編集できないようにしたりして。それだと差別になってしまうからだめですねSakayori_Hideki.icon
Ctrl+Zだけ覚えてもらえればなんとか…yosider.icon
包丁を落としたら危ないから、いつもカバーをかけておくのがいいのだろうか?みたいな。刃物の怖さをしらなきゃ、さわるのは危ないですからSakayori_Hideki.icon
今まではページの削除だけは簡単に復旧できなかったのですが、Streamから復元できるようになってよかったですtakker.icon
これで大抵の操作はもとに戻せるようになった
でも、一般に広く流行らせるためには、間違って更新できないようになればベターSakayori_Hideki.icon
遠い将来、VRゴーグルが実用化されたら、目線がカーソル近くや該当ページの上にあるときだけ更新できるようにならないかな・・なんて。いや無理か。
2つの方向性にまとめられそうtakker.icon
1. 間違った変更ができないようにする
2. (間違った)変更をしてもいつでもすぐに戻せるようにする
Scrapboxの方向性はこっちですね
はいshokai.icon